Skip to content

Conversation

@laurensvalk
Copy link
Member

@laurensvalk laurensvalk commented Oct 31, 2024

  • Allow faster flashing of smaller firmwares by erasing only as much as needed.
  • Work around USB3.0 issues with the EV3 bootloader. Thanks @JakubVanek for notes in this issue!

Since all of the changes could be done without any low level hacking of the HID API, this is very promising for when we make a web-based version in the future.

Changes have not been tested on a USB2.0 system yet, but there should be no changes.

Tested on a copy of the official firmware (16MiB).

And on a 1.5MiB Pybricks firmware, which now takes about 6 seconds to erase and 6 seconds to install, instead of up to two minutes or more.

- Allow faster flashing of smaller firmwares by erasing only as much as needed.
- Work around USB3.0 issues with the EV3 bootloader.
@BertLindeman
Copy link

Rats, I have a re-freshed clone on linux and wanted to test USB-2 flash.

It works, but I am not sure if i use the updated version.
Might there be a way to be sure I run the new flash.py?

I ran in the activated .venv in the git clone on an USB-2 plug:

pipx run pybricksdev flash /home/bert/Downloads/pybricks-firmware/nxt-firmware-build-3607-git9e5ef68d.zip
⚠️  pybricksdev is already on your PATH and installed at /home/bert/py/pybricks/git_clone/pybricksdev/.venv/bin/pybricksdev. Downloading and running anyway.
Creating firmware...
Looking for the NXT in SAM-BA mode...
Brick found!
Flashing firmware...
Flashing complete, jumping to 0x100000...
Firmware started.

In ../pybricksdev/cli/flash.py I do see the update.

        ERASE_TICKS = 60

So looks good, but . . .

Bert

Copy link
Member

@dlech dlech left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@laurensvalk laurensvalk merged commit 5a58e05 into master Nov 1, 2024
10 checks passed
@laurensvalk
Copy link
Member Author

@BertLindeman, this is an update for EV3. There were no changes for NXT.

@laurensvalk laurensvalk deleted the ev3 branch November 1, 2024 18:42
@BertLindeman
Copy link

@BertLindeman, this is an update for EV3. There were no changes for NXT.

Hard to read ;-) Thanks

JakubVanek added a commit to JakubVanek/ev3duder that referenced this pull request Jun 16, 2025
As noted in the linked commit (coming from pybricks/pybricksdev#98),
the hardware version can still be read even when the brick is plugged
into a USB 3.0 port.

Unforunately, the CRC packets likely cannot be salvaged this way -
the CRC request is longer than the CRC response and so the CRC value
is overwritten inside the brick.
JakubVanek added a commit to JakubVanek/ev3duder that referenced this pull request Jun 20, 2025
As noted in the linked commit (coming from pybricks/pybricksdev#98),
the hardware version can still be read even when the brick is plugged
into a USB 3.0 port.

Unforunately, the CRC packets likely cannot be salvaged this way -
the CRC request is longer than the CRC response and so the CRC value
is overwritten inside the brick.
JakubVanek added a commit to JakubVanek/ev3duder that referenced this pull request Jun 20, 2025
As noted in the linked commit (coming from pybricks/pybricksdev#98),
the hardware version can still be read even when the brick is plugged
into a USB 3.0 port.

Unforunately, the CRC packets likely cannot be salvaged this way -
the CRC request is longer than the CRC response and so the CRC value
is overwritten inside the brick.
JakubVanek added a commit to JakubVanek/ev3duder that referenced this pull request Jun 20, 2025
As noted in the linked commit (coming from pybricks/pybricksdev#98),
the hardware version can still be read even when the brick is plugged
into a USB 3.0 port.

Unforunately, the CRC packets likely cannot be salvaged this way -
the CRC request is longer than the CRC response and so the CRC value
is overwritten inside the brick.
JakubVanek added a commit to JakubVanek/ev3duder that referenced this pull request Jun 20, 2025
As noted in the linked commit (coming from pybricks/pybricksdev#98),
the EEPROM version can still be read even when the brick is plugged
into a USB 3.0 port.

Unforunately, the CRC packets likely cannot be salvaged this way -
the CRC request is longer than the CRC response and so the CRC value
is overwritten inside the brick.
JakubVanek added a commit to JakubVanek/ev3duder that referenced this pull request Jun 21, 2025
As noted in the linked commit (coming from pybricks/pybricksdev#98),
the EEPROM version can still be read even when the brick is plugged
into a USB 3.0 port.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants